It looks like this long-polling loop will fail to wait for longer than the server's long-poll timeout due to not handling DEADLINE_EXCEEDED. Can you compare to the implementations in Go and Python and add an integration test that demonstrates it can wait for longer than the server timeout, and for longer than the per-attempt client-side deadline? And also that it responds correctly when the activity is cancelled on the server.

Python:

        while True:
            try:
                res = await self._client.workflow_service.poll_activity_execution(
                    req,
                    retry=True,
                    metadata=rpc_metadata,
                    timeout=rpc_timeout,
                )
                if res.HasField("outcome"):
                    self._known_outcome = res.outcome
                    return
            except RPCError as err:
                if err.status == RPCStatusCode.DEADLINE_EXCEEDED:
                    # Deadline exceeded is expected with long polling; retry
                    continue
                elif err.status == RPCStatusCode.CANCELLED:
                    raise asyncio.CancelledError() from err
                else:
                    raise
            except asyncio.CancelledError:
                raise

Can you also check that activity cancellation is handled correctly in this loop?

The server behavior for polling timeout is to return empty response. This is handled correctly. The code throws exception on client-side deadline, but it could be argued it's the expected behavior - we can revisit is some other time, though it does match behavior of workflow result polling. Client-side cancellation is handled correctly.

Added tests to verify long long polling and client-side cancellation.

Ah, I guess you can only set them from inside the activity? We should support it in both places, but can be a follow up PR. Let's make sure we track it.

Non-blocking just since this is currently experimental, but making Info enforce that inWorkflow: true implies that workflowExecution etc are present would be nice

e.g.

  type Info = BaseInfo & (
    | { readonly inWorkflow: true;
        readonly workflowExecution: { workflowId: string; runId: string };
        readonly workflowNamespace: string;
        readonly workflowType: string;
        readonly activityRunId?: undefined }
    | { readonly inWorkflow: false;
        readonly activityRunId: string;
        readonly workflowExecution?: undefined;
        readonly workflowNamespace?: undefined;
        readonly workflowType?: undefined }
  );

This won't really work in a way that's helpful to the users, because ActivityContext.current().info still has to be the most general type and TS compiler doesn't support type assertions on this.

I don't believe this needs to be made public

It's not public, just privately exported within package. It's so it can be used in activity-client.ts.

Just to be more honest with the cast

Not major, but we usually throw IllegalStateError when attempting to use workflow only code in non-workflow contexts